fix(enclave): verify email and data owners from the Confidential Space token - #9548

Problem

On Confidential Space, attest_peer checked the enclave's email and data owners against the
claims document the enclave publishes itself. The token only bound that document by a sha256 in
eat_nonce. Any code running in the container, including a job, can call the launcher socket
and get a valid Google-signed token over a document naming different data owners. Image digest,
signature and every other check still pass, so a malicious job could change who approves jobs
without failing attestation.

Fix

The launcher already records the operator's tee-env-* values in the token, under
submods.container.env_override, before the container starts. No deployment change is needed:
terraform and the Justfile already set both variables, and the Dockerfile allows them.

• Email and data owners come from the token. They're read from env_override and compared
  with the policy through the shared check_expected(). env isn't used, because it also holds
  image ENV defaults.
• Missing values fail. A pinned value the token doesn't record fails the check, so it can't
  fall back to the enclave's own word.
• The claims document stays, for the key. It still binds key_bundle, which only exists at
  runtime. It must now also agree with env_override; if it doesn't, claims_binding fails and
  the key isn't adopted.
• Display: structure_claims() shows env_override.

Asana

https://app.asana.com/1/1185126988600652/project/1210542925864934/task/1218794314078561